Einheit 9 — Workflows dokumentieren und übergeben
Was du nach dieser Einheit weißt: Du weißt was dokumentiert sein muss, damit jemand anderes deinen Workflow warten und weiterentwickeln kann — ohne dich fragen zu müssen.
Warum dokumentieren?
Du baust einen Workflow. Er läuft. Du wendest dich dem nächsten Projekt zu. Sechs Monate später ruft ein Kollege an: „Der Rechnungs-Workflow macht Fehler. Kannst du mir erklären wie der funktioniert?"
Wenn die Antwort ist „den musst du durchklicken und selbst rausfinden" — dann ist der Workflow nicht produktionsreif. Ein Workflow der nicht ohne seinen Erbauer gewartet werden kann, ist ein Risiko.
📹 Video: [Platzhalter — Szenario-Video: Ein Kollege übernimmt einen undokumentierten Workflow — Frustration und Zeitverlust vs. ein gut dokumentierter Workflow — sofort handlungsfähig]
Was dokumentiert sein muss
1. Zweck des Workflows
Eine ein- bis zweisätzige Beschreibung: Was tut dieser Workflow? Für wen? Warum gibt es ihn?
Beispiel:
„Verarbeitet Eingangsrechnungen die per E-Mail an rechnungen@firma.de eingehen. Extrahiert Rechnungsdaten per KI, gleicht sie mit Bestellungen im ERP ab und bucht bei Übereinstimmung automatisch. Bei Abweichungen wird die Buchhaltung per E-Mail benachrichtigt."
📸 Screenshot: [Platzhalter — Workflow-Beschreibungsfeld in 42°OS: Ausgefüllt mit Zweck, Auslöser und Verhalten bei Fehlern]
2. Auslöser
Wie wird der Workflow gestartet? Was muss passieren, damit er losläuft?
- „Wird durch eingehende E-Mail an rechnungen@firma.de ausgelöst"
- „Läuft täglich um 06:00 Uhr über einen Scheduler"
- „Wird manuell über das Web-Formular gestartet"
- „Wird von Workflow XY über Source/Receiver aufgerufen"
3. Abhängigkeiten
Welche externen Systeme, Credentials und Ressourcen braucht der Workflow?
| Abhängigkeit | Credential | Zweck |
|---|---|---|
| ERP-System (SAP) | erp-prod-api | Kreditor suchen, Bestellung abgleichen, Rechnung buchen |
| DMS (ELO) | dms-prod-api | Rechnungs-PDF archivieren |
| E-Mail (Microsoft 365) | m365-prod-graph | Eingehende E-Mails lesen, Benachrichtigungen senden |
| SMB Share | smb-prod-eingangsrechnungen | Fallback: Rechnungen die nicht per E-Mail kommen |
4. Abschnitte und ihre Funktion
Wenn der Workflow modular aufgebaut ist: welcher Abschnitt (Workflow) tut was?
| Workflow | Funktion | Eingang | Ausgang |
|---|---|---|---|
| Eingangsrechnung — E-Mail empfangen | E-Mail abholen, Anhang extrahieren, nur PDFs durchlassen | PDF + Absender-Info | |
| Eingangsrechnung — Daten extrahieren | Rechnungsdaten per KI aus PDF lesen, in DB normalisieren | Strukturierte Rechnungsdaten | |
| Eingangsrechnung — ERP-Abgleich | Kreditor und Bestellung im ERP suchen, Betrag prüfen | Rechnungsdaten | Buchungsstatus |
| Eingangsrechnung — Abschluss | Rechnung im DMS ablegen, Bestätigung/Eskalation senden | Buchungsstatus + PDF | — |
5. Bekannte Einschränkungen
Was kann der Workflow nicht? Wo sind die Grenzen?
- „Verarbeitet nur Rechnungen mit einer Seite. Mehrseitige Rechnungen werden nicht unterstützt."
- „Kreditgutschriften werden nicht erkannt und landen in der Eskalation."
- „Wenn der ERP-Server nicht erreichbar ist, werden Rechnungen in der Warteschlange gesammelt. Die Warteschlange muss manuell angestoßen werden."
6. Ansprechpartner und Verantwortlichkeit
Wer hat den Workflow gebaut? Wer ist für die Wartung verantwortlich? An wen gehen Eskalationen?
| Rolle | Person | Kontakt |
|---|---|---|
| Erstellt von | Max Müller | max@firma.de |
| Fachlich verantwortlich | Buchhaltung / Frau Schmidt | schmidt@firma.de |
| Technisch verantwortlich | IT / Max Müller | max@firma.de |
| Eskalation geht an | Frau Schmidt (fachlich), Max Müller (technisch) | — |
Wo dokumentieren?
Idealerweise dort, wo die Information gebraucht wird:
| Information | Wo |
|---|---|
| Zweck, Auslöser, Einschränkungen | Beschreibungsfeld des Workflows in 42°OS |
| Agent-Zweck | Agent-Name (sprechend benennen, siehe Einheit 5) |
| Komplexe Agent-Logik | Beschreibungsfeld des Agents |
| Gesamtdokumentation mit Abhängigkeiten, Abschnitten, Ansprechpartnern | Separates Dokument (Wiki, Confluence, DMS, oder Markdown-Datei) |
| Testfälle | Separater Ordner mit JSON-Testdaten und Test-PDFs |
📸 Screenshot: [Platzhalter — Beschreibungsfeld eines Workflows in 42°OS: Zweck, Auslöser und Einschränkungen ausgefüllt]
📸 Screenshot: [Platzhalter — Beschreibungsfeld eines Agents in 42°OS: Erklärung einer komplexen Switch-Bedingung]
Übergabe-Checkliste
Wenn du einen Workflow an jemand anderen übergibst, gehe diese Liste durch:
- Zweck und Auslöser sind dokumentiert
- Alle Abhängigkeiten (Systeme, Credentials) sind aufgelistet
- Abschnitte und ihre Funktion sind beschrieben
- Bekannte Einschränkungen sind dokumentiert
- Ansprechpartner und Verantwortlichkeiten sind geklärt
- Testfälle sind vorhanden und übergeben
- Der Empfänger hat Zugriff auf alle benötigten Credentials und Systeme
- Eine gemeinsame Durchsprache hat stattgefunden (nicht nur Dokument übergeben)
📹 Video: [Platzhalter — Screencast: Einen Workflow übergeben — Dokumentation zeigen, gemeinsam durch den Workflow klicken, Testfall durchlaufen]
Dokumentation muss nicht perfekt sein. Eine halbe Seite mit Zweck, Abhängigkeiten und Einschränkungen ist unendlich besser als gar nichts.
Weiter: Einheit 10 — Checkliste: Ist mein Workflow produktionsreif?